Toshiba TX39 development

Contents|Index|Previous|Next
Toshiba TX39 development

The following documentation discusses the TX39 processor.

- Compiler issues for TX39 targets
- ABI summary for the Toshiba TX39 targets
- Assembler issues for TX39 targets
- Linker issues for TX39 targets
- Debugger issues for TX39 targets
- Simulator issues for TX39 targets

GNUPro Toolkit is a complete solution for C and C++ development for the Toshiba TX39. The tools include the compiler, interactive debugger and utilities libraries. Debugger and linker support is also included for the Densan DVE-R3900/20 evaluation board.
Cross-development tools in GNUPro Toolkit normally have names that reflect the target processor and the object file format output by the tools (for example, ELF). This makes it possible to install more than one set of tools in the same binary directory, including both native and cross-development tools.
The complete tool name is a four-part hyphenated string. For example, the GCC compiler for the Toshiba TX39 is `mips-tx39-elf-gcc`. The first part indicates the processor family (`mips`).
The second part indicates the processor (`tx39`). The third part indicates the file format output by the tool (`elf`). The fourth part is the generic tool name (`gcc`).
The binaries for a Windows 95/NT hosted toolchain are installed with an `.exe` suffix. However, the `.exe` suffix does not need to be specified when running the executable.
The TX39 package includes the following supported tools.

Tool description | Tool name
GCC compiler | `mips-tx39-elf-gcc`
C++ compiler | `mips-tx39-elf-c++`
GAS assembler | `mips-tx39-elf-as`
GNU linker | `mips-tx39-elf-ld`
Standalone simulator | `mips-tx39-elf-run`

Binary utilities

`mips-tx39-elf-ar`
`mips-tx39-elf-nm`
`mips-tx39-elf-objcopy`
`mips-tx39-elf-objdump`
`mips-tx39-elf-ranlib`
`mips-tx39-elf-size`
`mips-tx39-elf-strings`
`mips-tx39-elf-strip`

GDB debugger | `mips-tx39-elf-gdb`

The TX39 can also port to the following targets. Both targets run in big-endian mode.

- GNUPro Instruction Set simulator
- Densan DVE-R3900/20 evaluation board

The TX39 supports the following hosts.

Host | Vendor
SunOS 4.1.4 (SPARC) | Sun
Solaris 2.4-2.5.1 (SPARC) | Sun
Windows NT (x86) | Microsoft
Windows 95 (x86) | Microsoft

The TX39 tools support the ELF object file format. See Chapter 4 of System V Application Binary Interface (Prentice Hall, 1990.). Use `ld` (see Using `ld` in GNUPro Utilities) or `objcopy` (see Using `binutils` in GNUPro Utilities) to produce S-records.
Compiler issues for TX39 targets
The following documentation describes TX39-specific features of the GNUPro compiler.
For a list of available generic compiler options, see GNU CC command options in Using GNU CC in GNUPro Compiler Tools. In addition, the following TX39-specific command-line options are supported.

`-msoft-float`

This option is on by default. It causes the compiler to generate output containing library calls for floating point operations.

`-msingle-float`

This option causes the compiler to generate output containing floating point instructions for single precision floating point operations, and library calls for double precision floating point operations.

`-EB`

`-EL`

Any MIPS configuration of the compiler can select big-endian or little-endian output at run time. Use `-EB` to select big-endian output and `-EL` for little-endian. If neither `-EL` nor `-EB` are defined, big-endian is the default.

There are no TX39-specific attributes. See Declaring attributes of functions and Specifying attributes of variables in Using GNU CC in GNUPro Compiler Tools for more information.
The compiler supports the following preprocessor symbols.

`__mips__`
`__R3000__`

Each of these is always defined.

`__MIPSEL__`
`__MIPSEB__`

One of these will be defined depending on the endian compilation mode.

`__mips_single_float`
`__mips_soft_float`

One of these will be defined depending on the floating point compilation mode.

ABI summary for the Toshiba TX39 targets
The following documentation describes the MIPS EABI, to which the TX39 tools adhere by default.

- Data type sizes and alignments
- Subroutine calls for TX39
- The stack frame for TX39 targets
- Parameter assignments for registers for TX39
- Structure passing for TX39 targets
- Varargs handling for TX39 targets
- Function return values for TX39 targets

Data type sizes and alignments
The following table shows the size and alignment for all data types.

Type | Size (bytes) | Alignment (bytes)
`char :` | 1 byte | 1 byte
`short :` | 2 bytes | 2 bytes
`int :` | 4 bytes | 4 bytes
`unsigned :` | 4 bytes | 4 bytes
`long :` | 4 bytes | 4 bytes
`long long :` | 8 bytes | 8 bytes
`float :` | 4 bytes | 4 bytes
`double :` | 8 bytes | 8 bytes
pointer`:` | 4 bytes | 4 bytes

- Alignment within aggregates (structs and unions) is as above, with padding added if needed
- Aggregates have alignment equal to that of their most aligned member
- Aggregates have sizes which are a multiple of their alignment

Subroutine calls for the TX39
The following documentation describes the calling conventions for subroutine calls: parameter registers for passing parameters and other register usage.

Parameter registers
general-purpose | `r4` through `r11`
floating point | `f12` through `f19`

Register usage
fixed 0 value | `r0`
volatile | `r1` through `r15`, as well as `r24` and `r25`
non-volatile | `r16` through `r23`,as well as `r30`
kernel reserved | `r26`,`r27`
gp (SDA base) | `r28`
stack pointer | `r29`
frame pointer | `r30` (if needed)
return address | `r31`

- General-purpose and floating point parameter registers are allocated independently.
- Structures that are less than or equal to 32 bits are passed as values.
- Structures that are greater than 32 bits are passed as pointers.

The stack frame for TX39 targets
The following documentation describes the TX39 stack frame.

- The stack grows downwards from high addresses to low addresses.
- A leaf function need not allocate a stack frame if it does not need one.
- A frame pointer need not be allocated.
- The stack pointer shall always be aligned to 8 byte boundaries.

Stack frames for functions that take a fixed number of arguments have the following settings.

* If no `alloca` region, the frame pointer (FP) points to the same place as the stack pointer (SP).

Stack frames for functions that take a variable number of arguments have the following settings.

* If no `alloca` region, the frame pointer (FP) points to the same place as the stack pointer (SP).

Parameter assignment to registers for TX39 targets
Consider the parameters in a function call as ordered from left (first parameter) to right. In the following algorithm, FR contains the number of the next available floating-point register (or register pair for modes in which floating-point registers hold only 32 bits). GR contains the number of the next available general-purpose register. STARG is the address of the next available stack parameter word.

##### INITIALIZE

Set GR=r4, FR=f12, and STARG to point to parameter word 1.

##### SCAN

If there are no more parameters, terminate. Otherwise, select one of the following depending on the type of the next parameter:

##### DOUBLE OR FLOAT

If FR > f19, go to STACK. Otherwise, load the parameter value into floating-point register FR and advance FR to the next floating-point register (or register pair in 32-bit mode). Then go to SCAN.

##### SIMPLE ARG

A SIMPLE ARG is one of the following types:

- One of the simple integer types which will fit into a general-purpose register
- A pointer to an object of any type
- A struct or union small enough to fit in a register
- A larger struct or union, which shall be treated as a pointer to the object or to a copy of the object (See below for when copies are made.)

If GR > r11, go to STACK. Otherwise, load the parameter value into general-purpose register GR and advance GR to the next general-purpose register. Values shorter than the register size are sign-extended or zero-extended depending on whether they are signed or unsigned. Then go to SCAN.

##### LONG LONG in 32-bit mode

If GR > r10, go to STACK. Otherwise, if GR is odd, advance GR to the next register. Load the 64-bit `long long` value into register pair GR and GR+1. Advance GR to GR+2 and go to SCAN.

##### STACK

Parameters not otherwise handled in the previous discussions for register assignments are passed in the parameter words of the callers stack frame. SIMPLE ARGs, as defined above, are considered to have size and alignment equal to the size of a general-purpose register, with simple argument types shorter than this sign- or zero-extended to this width. float arguments are considered to have size and alignment equal to the size of a floating-point register. In 64-bit mode, floats are stored in the low-order 32 bits of the 64-bit space allocated to them. `double` and `long long` are considered to have 64-bit size and alignment. Round STARG up to a multiple of the alignment requirement of the parameter and copy the argument byte-for-byte into STARG, STARG+1, ... STARG+size-1. Set STARG to STARG+size and go to SCAN.

Structure passing for TX39 targets
Code that passes structures and unions by value is implemented specially. ("struct" will refer to structs and unions, inclusively.) Structs small enough to fit in a register are passed by value in a single register or in a stack frame slot the size of a register. Larger structs are handled by passing the address of the structure. In this case, a copy of the structure will be made if necessary in order to preserve the pass-by-value semantics. Copies of large structs are made under the following rules.

| ANSI mode | K&R mode
Normal param | Callee copies if needed | Caller copies
Varargs (...) param | Caller copies | Caller copies

In the case of normal (non-varargs) large-struct parameters in ANSI mode, the callee is responsible for producing the same effect as if a copy of the structure were passed, preserving the pass-by-value semantics. This may be accomplished by having the callee make a copy, but in some cases the callee may be able to determine that a copy is not necessary in order to produce the same results. In such cases, the callee may choose to avoid making a copy of the parameter.
Varargs handling for TX39 targets
No special changes are needed for handling `varargs` parameters other than the caller knowing that a copy is needed on struct parameters larger than a register (see Structure passing for TX39 targets).
The `varargs` macros set up a two-part register save area, one part for the general-purpose registers and one part for floating-point registers, and maintain separate pointers for these two areas and for the stack parameter area. The register save area lies between the caller and callee stack frame areas.
In the case of software floating-point, only the general-purpose registers need to be saved.
Because the save area lies between the two stack frames, the saved register parameters are contiguous with parameters passed on the stack. This allows the varargs macros to be much simpler. Only one pointer is needed, advancing from the register save area into the callers stack frame.
Function return values for TX39 targets
Data types and register usage use the following return values.

Data type | Register
`int` : | `r2`
`short` : | `r2`
`long` : | `r2`
`long long` : | `r2` through `r3` (32-bit mode)
`float` : | `f0`
`double` : | `f0` through `f1` (32-bit mode)
`struct/union` : | (see following discussion)

Structures and unions that will fit into two general-purpose registers are returned in `r2`, or in `r2` and `r3`, if necessary. They are aligned within the register according to the endianness of the processor; for example, on a big-endian processor the first byte of the struct is returned in the most significant byte of `r2`, while on a little-endian processor the first byte is returned in the least significant byte of `r2`. The caller handles larger structures and unions, by passing, as a "hidden" first argument, a pointer to space allocated to receive the return value.

Assembler issues for TX39 targets

The following documentation describes TX39-specific features of the GNUPro assembler.

- Register names for TX39 targets
- Assembler directives for TX39 targets
- MIPS synthetic instructions supported for the TX39 targets

For a list of available generic assembler options, see Command-line options in Using `as` in GNUPro Utilities.

`-EB`
`-EL`

Any MIPS configuration of the assembler can select big-endian or little-endian output at run time.

Use `-EB` to select big-endian output, and `-EL` for little-endian output. The default is big-endian.

For information about the MIPS instruction set, see MIPS RISC Architecture, (Kane and Heindrich, Prentice-Hall). For an overview of MIPS assembly conventions, see "Appendix D: Assembly Language Programming" in MIPS RISC Architecture.
Register names for TX39 targets
There are 32 64-bit general (integer) registers, named `$0` through `$31`. There are 32 64-bit floating-point registers, named `$f0` through `$f31`.
The symbols, `$0` through `$31`, refer to the general-purpose registers.
The following symbols can be used as aliases for individual registers.

Symbol | Register
`$at` | `$1`
`$kt0` | `$26`
`$kt1` | `$27`
`$gp` | `$28`
`$sp` | `$29`
`$fp` | `$30`

Assembler directives for TX39 targets

The following list shows the TX39 assembler directives.

`.abicalls` | `.dcb.b` | `.fail` | `.irepc` | `.psize`
`.abort` | `.dcb.d` | `.file` | `.irp` | `.purgem`
`.aent` | `.dcb.l` | `.fill` | `.irpc` | `.quad`
`.align` | `.dcb.s` | `.float` | `.lcomm` | `.rdata`
`.appfile` | `.dcb.w` | `.fmask` | `.lflags` | `.rep`
`.appline` | `.dcb.x` | `.format` | `.linkonce` | `.rept`
`.ascii` | `.debug` | `.frame` | `.list` | `.rva`
`.asciiz` | `.double` | `.global` | `.livereg` | `.sbttl`
`.asciz` | `.ds` | `.globl` | `.llen` | `.sdata`
`.balign` | `.ds.b` | `.gpword` | `.loc` | `.set`
`.balignl` | `.ds.d` | `.half` | `.long` | `.short`
`.balignw` | `.ds.l` | `.hword` | `.lsym` | `.single`
`.bgnb` | `.ds.p` | `.if` | `.macro` | `.skip`
`.bss` | `.ds.s` | `.ifc` | `.mask` | `.space`
`.byte` | `.ds.w` | `.ifdef` | `.mexit` | `.spc`
`.comm` | `.ds.x` | `.ifeq` | `.mri` | `.stabd`
`.common` | `.dword` | `.ifeqs` | `.name` | `.stabn`
`.common.s` | `.eject` | `.ifge` | `.noformat` | `.stabs`
`.cpadd` | `.else` | `.ifgt` | `.nolist` | `.string`
`.cpload` | `.elsec` | `.ifle` | `.nopage` | `.struct`
`.cprestore` | `.end` | `.iflt` | `.octa` | `.text`
`.data` | `.endb` | `.ifnc` | `.offset` | `.title`
`.dc` | `.endc` | `.ifndef` | `.option` | `.ttl`
`.dc.b` | `.endif` | `.ifne` | `.org` | `.verstamp`
`.dc.d` | `.ent` | `.ifnes` | `.p2align` | `.word`
`.dc.l` | `.equ` | `.ifnotdef` | `.p2alignl` | `.xcom`
`.dc.s` | `.equiv` | `.include` | `.p2alignw` | `.xdef`
`.dc.w` | `.err` | `.insn` | `.page` | `.xref`
`.dc.x` | `.exitm` | `.int` | `.plen` | `.xstabs`
`.dcb` | `.extern` | `.irep` | `.print` | `.zero`

MIPS synthetic instructions supported for the TX39
The TX39 GAS assembler supports the typical MIPS synthetic instructions (macros). What follows is a list of synthetic instructions supported by the assembler, as well as an example expansion of each instruction. The following helps to follow the list of instructions.

- `R` = register
- `I` = immediate
- `E` = expression (usually a memory expression, `addr` + `offset`).

Instruction | Expansion
--- | ---
`abs R R` | `bgez $a0,0x5c` `move $t1,$a0` `neg $t1,$a0`

`div R R R`

`div $zero,$t1,$a0`
`bnez $a0,0x120`
`nop`
`break 0x7`
`li $at,-1`
`bne $a0,$at,0x138`
`lui $at,0x8000`
`bne $t1,$at,0x138`
`nop`
`break 0x6`
`mflo $a3`

`div R R`

`div $zero,$a3,$t1`
`bnez $t1,0x154`
`nop`
`break 0x7`
`li $at,-1`
`bne $t1,$at,0x16c`
`lui $at,0x8000`
`bne $a3,$at,0x16c`
`nop`
`break 0x6`
`mflo $a3`

`div R R I` | `li $at,<I>` `div $zero,$a3,$at` `mflo $a1`
`divu R R R` | `divu $zero,$a0,$a2` `bnez $a2,0x1cc` `nop` `break 0x7` `mflo $t1`
`divu R R` | `divu $zero,$t1,$a0` `bnez $a0,0x1e8` `nop` `break 0x7` `mflo $t1`
`divu R R I` | `li $at,<I>` `divu $zero,$v1,$at` `mflo $t0`
`jal E` | `jalr <E>`
`lwc0 R I` | `ll <R> <I>`
`mul R R R` | `multu $t0,$v1` `mflo $a2`
`mul R R I` | `li $at,<I>` `mult $t0,$at` `mflo $a2`

`mulo R R R`

`mult $t0,$v1`
`mflo $a2`
`sra $a2,$a2,0x1f`
`mfhi $at`
`beq $a2,$at,0x440`
`nop`
`break 0x6`
`mflo $a2`

`mulou R R R` | `multu $t0,$v1` `mfhi $at` `mflo $a2` `beqz $at,0x464` `nop` `break 0x6`
`nor R R I` | `ori $t1,$a0,0xe` `nor $t1,$t1,$zero`
`not R R` | `nor $t1,$a0,$zero`
`or R R I` | `ori $a2,$t0,<I>`

`rem R R R`

`div $zero,$t1,$a0`
`bnez $a0,0x4ec`
`nop`
`break 0x7`
`li $at,-1`
`bne $a0,$at,0x504`
`lui $at,0x8000`
`bne $t1,$at,0x504`
`nop`
`break 0x6`
`mfhi $a3`

`rem R R I` | `li $at,11` `div $zero,$t1,$at` `mfhi $a3`
`remu R R R` | `divu $zero,$v1,$a1` `bnez $a1,0x564` `nop` `break 0x7` `mfhi $t0`
`remu R R I` | `li $at,<I>` `divu $zero,$a0,$at` `mfhi $t1`
`rol R R R` | `negu $at,$a3` `srlv $at,$a1,$at` `sllv $v1,$a1,$a3` `or $v1,$v1,$at`
`rol R R I` | `sll $at,$v1,<I>` `srl $t0,$v1,0x11` `or $t0,$t0,$at`
`ror R R R` | `negu $at,$a1` `sllv $at,$v1,$at` `srlv $t0,$v1,$a1` `or $t0,$t0,$at`
`ror R R I` | `srl $at,$t0,<I>` `sll $a2,$t0,0x11` `or $a2,$a2,$at`
`sd R E` | `sw $a1,<E>` `sw $a2,<E+4>`
`seq R R R` | `xor $t1,$a0,$a2` `sltiu $t1,$t1,1`
`seq R R I` | `xori $a3,$t1,<I>` `sltiu $a3,$a3,1`
`sge R R R` | `slt $a3,$t1,$a0` `xori $a3,$a3,0x1`
`sge R R I` | `slti $a1,$a3,<I>` `xori $a1,$a1,0x1`
`sgeu R R R` | `sltu $a1,$a3,$t1` `xori $a1,$a1,0x1`
`sgeu R R I` | `sltiu $a0,$a2,<I>` `xori $a0,$a0,0x1`
`sgt R R R` | `slt $a1,$t1,$a3`
`sgt R R I` | `li $at,<I>` `slt $v1,$at,$a1`
`sgtu R R R` | `sltu $v1,$a3,$a1`
`sgtu R R I` | `li $at,<I>` `sltu $t1,$at,$a0`
`sle R R R` | `slt $v1,$a3,$a1` `xori $v1,$v1,0x1`
`sle R R I` | `li $at,<I>` `slt $t0,$at,$v1` `xori $t0,$t0,0x1`
`sleu R R R` | `sltu $t0,$a1,$v1` `xori $t0,$t0,0x1`
`sleu R R I` | `li $at,<I>` `sltu $a3,$at,$t1` `xori $a3,$a3,0x1`
`sll R R R` | `sllv $t0,$v1,$a1`
`slt R R I` | `slti $a3,$t1,<I>`
`sltu R R I` | `sltiu $a3,$t1,<I>`
`sne R R R` | `xor $a1,$a3,$t1` `sltu $a1,$zero,$a1`
`sne R R I` | `xori $v1,$a1,<I>` `sltu $v1,$zero,$v1`
`sra R R R` | `srav $a0,$a2,$t0`
`srl R R R` | `srlv $v1,$a1,$a3`
`sub R R I` | `addi $a0,$a2,-<I>`
`subu R R I` | `addiu $t1,$a0,-<I>`
`swc0 R E` | `sc $a1,<E>`
`ulh R E` | `lb $a0,<E>` `lbu $at,<E+1>` `sll $a0,$a0,0x8` `or $a0,$a0,$at`
`ulhu R E` | `lbu $a0,<E>` `lbu $at,<E+1>` `sll $a0,$a0,0x8` `or $a0,$a0,$at`
`ulw R E` | `lwl $a2,<E>` `lwr $a2,<E+K>`
`ush R E` | `sb $a2,<E+K>` `srl $at,$a2,0x8` `sb $at,<E>`
`usw R E` | `swl $a2,<E>` `swr $a2,<E+K>`
`xor R R I` | `xori $a2,$t0,0x10`

Linker issues for TX39 targets

The TX39-specific features of the GNUPro linker can be found in the Linker script for TX39 targets.

For a list of available generic linker options, see Linker scripts in Using `ld` in GNUPro Utilities. There are no TX39-specific command-line linker options.

Linker script for TX39 targets
The GNU linker uses a linker script to determine how to process each section in an object file, and how to lay out the executable. The linker script is a declarative program consisting of a number of directives. For instance, the `ENTRY()` directive specifies the symbol in the executable that will be the executable's entry point.
The following linker script is `dve.ld`, a linker script for the Densan DVE-R3900/A20 board.

      /* Linker script for Densan DVE-R3900/20A board */

     ENTRY(_start)

     OUTPUT_ARCH("mips:3000")

     OUTPUT_FORMAT("elf32-bigmips", "elf32-bigmips", "elf32-littlemips")

     GROUP(-lc -ldve -lgcc)

     SEARCH_DIR(.)

     __DYNAMIC = 0;

     /*

      * Allocate the stack to be at the top of memory, since the

      * stack grows down

      */

     PROVIDE (__stack = 0);

     /* PROVIDE (__global = 0); */

     /*

      * Initalize some symbols to be zero so we can reference them

      * in the crt0 without core dumping. These functions are all

      * optional, but we do this so we can have our crt0 always use

      * them if they exist.

      * This is so BSPs work better when using the crt0 installed

      * with gcc.

      * We have to initalize them twice, so we multiple object file

      * formats, as some prepend an underscore.

      */

     PROVIDE (hardware_init_hook = 0);

     PROVIDE (software_init_hook = 0);

     SECTIONS

     {

      . = 0xA0040000;

      .text : {

        _ftext = . ;

        *(.init)

        eprol = .;

        *(.text)

        *(.mips16.fn.*)

        *(.mips16.call.*)

        PROVIDE (__runtime_reloc_start = .);

        *(.rel.sdata)

        PROVIDE (__runtime_reloc_stop = .);

        *(.fini)

        etext = .;

        _etext = .;

     }

     . = .;

     .rdata : {

        *(.rdata)

     }

      _fdata = ALIGN(16);

      .data : {

        *(.data)

        CONSTRUCTORS

     }

     . = ALIGN(8);

     _gp = . + 0x8000;

     __global = _gp;

     .lit8 : {

       *(.lit8)

     }

     .lit4 : {

       *(.lit4)

     }

     .sdata : {

       *(.sdata)

     }

     . = ALIGN(4);

     edata = .;

     _edata = .;

     _fbss = .;

     .sbss : {

       *(.sbss)

       *(.scommon)

     }

     .bss : {

       _bss_start = . ;

       *(.bss)

       *(COMMON)

     }

     end = .;

     _end = .;

     /* DWARF debug sections.

       Symbols in the DWARF debugging sections are relative to

       the beginning of the section so we begin them at 0. */

     /* DWARF 1 */

     .debug 0 : { *(.debug) }

     .line 0 : { *(.line) }

     /* GNU DWARF 1 extensions */

     .debug_srcinfo 0 : { *(.debug_srcinfo) }

     .debug_sfnames 0 : { *(.debug_sfnames) }

     /* DWARF 1.1 and DWARF 2 */

     .debug_aranges 0 : { *(.debug_aranges) }

     .debug_pubnames 0 : { *(.debug_pubnames) }

     /* DWARF 2 */

     .debug_info 0 : { *(.debug_info) }

     .debug_abbrev 0 : { *(.debug_abbrev) }

     .debug_line 0 : { *(.debug_line) }

     .debug_frame 0 : { *(.debug_frame) }

     .debug_str 0 : { *(.debug_str) }

     .debug_loc 0 : { *(.debug_loc) }

     .debug_macinfo 0 : { *(.debug_macinfo) }

      /* SGI/MIPS DWARF 2 extensions */

      .debug_weaknames 0 : { *(.debug_weaknames) }

      .debug_funcnames 0 : { *(.debug_funcnames) }

      .debug_typenames 0 : { *(.debug_typenames) }

      .debug_varnames 0 : { *(.debug_varnames) }

    }

Debugger issues for TX39 targets
The following documentation describes TX39-specific features of the GNUPro debugger. There are three ways for GDB to talk to a TX39 target.

- Simulator
GDBs built-in software simulation of the TX39 processor allows the debugging of programs compiled for the TX39 without requiring any access to actual hardware. To activate this mode in GDB type `target sim` . Then load the code into the simulator by typing `load` and debug it in the normal fashion.
- Remote target board by serial connection
To connect to the target board in GDB, using the command
`target remote` `<devicename>` where `<devicename>` will be a serial device such as `/dev/ttya` (Unix) or `com2` (Windows NT). Then load the code onto the target board by using the command, `load`. After being downloaded, the program can be executed. The target command would be something like the following example's input after the `(gdb)` prompt.

    (gdb) target r3900 205.180.230.151:1600

- Remote target board by ethernet connection :
Connecting to the ethernet port with GDB is very similar to connecting to a serial port. The target command would be something like the following example's input after the `(gdb)` prompt.

    (gdb) target r3900 205.180.230.151:1600

If the system administrator has assigned a host name to the board, you can use that name in the target command instead of the dotted IP address. For example, if the board is named tx39a, use the following examples input after the `(gdb)` prompt.

    (gdb) target r3900 tx39a:1600

It is important to specify the port number. The exact number is not important, but it must be the same number that you used to configure the board.

No special GDB commands are necessary to perform fast downloading of programs via the ethernet. Simply use the normal `load` command. GDB recognizes that the board is connected via ethernet, and will use a fast binary downloading method.

For the available generic debugger options, see Debugging with GDB in GNUPro Debugging Tools. There are no TX39 specific debugger command-line options.
Simulator issues for TX39 targets
The following documentation describes TX39-specific features of the GNUPro simulator.
The TX39 simulator includes support for 32, 32-bit general-purpose registers.
The user program is provided with a single 2Mb block of memory at address, `0xa0000000` (shadowed at address, `0x80000000`).
The following general options, are supported by the simulator:

`--help`

The following example shows how to list the MIPS-specific help options, as printed by the `--help` option.

`% tx39-elf-run --help`
`Usage: run [options] program [program args]`
`Options:`
`-l FILE, --log FILELog file`
`-n MODEL, --name MODELSelect arch model`
`-p[on|off], --profile [on|off]`
`Enable profiling`
`-t[on|off], --trace [on|off]`
`Enable tracing`
`-z FILE, --tracefile FILEWrite trace to file`
`-y FREQ, --frequency FREQProfile frequency`
`-y SIZE, --samples SIZE Profile sample size`

`--trace=[on|off]`

This option creates a file called `trace.din` that contains tracing information. Use the `--tracefile` switch to change the name of the output file.

    % tx39-elf-run --trace hello

    Hello, world!

    3 + 4 = 7

The following output shows the first 10 lines of the file produced by the previous command.

`2 a0040004 ; width 4 ; load instruction`
`2 a0040008 ; width 4 ; load instruction`
`2 a004000c ; width 4 ; load instruction`
`2 a0040010 ; width 4 ; load instruction`
`2 a0040014 ; width 4 ; load instruction`
`2 a0040018 ; width 4 ; load instruction`
`2 a004001c ; width 4 ; load instruction`
`2 a0040020 ; width 4 ; load instruction`
`2 a0040024 ; width 4 ; load instruction`
`2 a0040028 ; width 4 ; load instruction`

`--tracefile <file>`

This option changes the name of the `<file>` to which trace information will be written.

    % mips-tx39-elf-run --trace --tracefile=trace.out hello

    Placing trace information into file "trace.out"

    Hello, world!

    3 + 4 = 7

`--profile [on|off]`

This option creates a file called `gmon.out` that contains profiling information. This file can be used as input to `gprof`, the GNU profiler.

    % mips-tx39-elf-run --trace hello

    Hello, world!

    3 + 4 = 7

`--frequency <frequency>`

By default, the simulator samples the running program every 256 instructions. This option allows you to change this profiling frequency to some other number. Smaller numbers increasing the accuracy of the profile, but make the simulator run slightly slower. Also, because the counters used in the profile are only 16 bits, a high sampling frequency may cause the counters to overflow.

    % mips-tx39-elf-run --profile --frequency 128 hello

    Hello, world!

    3 + 4 = 7

`--samples <size>`

By default, the simulator uses a profiling sample size of 131072 (128K). This option allows you to change the sample `<size>`. Increasing the sample size will make the profile more accurate, but will also increase the size of the profile output file (`gmon.out`).

The simulator rounds the sample size up the next power of two.

    % mips-tx39-elf-run --profile --samples 20000 hello

    Hello, world!

    3 + 4 = 7

Top|Contents|Index|Previous|Next